\documentclass[11pt,a4paper]{article}
\usepackage{ifpdf}
\usepackage[utf8]{inputenc}
\usepackage[francais]{babel}
\usepackage[T1]{fontenc}
\usepackage[nottoc, notlof, notlot]{tocbibind}
\usepackage[unicode=true,pdftex,colorlinks=true,linkcolor=black,urlcolor=black,
  citecolor=black]{hyperref}
\usepackage{natbib}
\usepackage[pdftex]{graphicx}
%\usepackage[usenames,dvipsnames]{color}
\usepackage{listings}
\usepackage{float}
\usepackage{tabularx}
\usepackage[table]{xcolor}
\usepackage{array}
\usepackage{tabularx}
\usepackage{enumerate}
\usepackage{url}

\definecolor{colKeys}{rgb}{0,0,1}
\definecolor{colIdentifier}{rgb}{0,0,0}
\definecolor{colComments}{rgb}{0,0.5,1}
\definecolor{colString}{rgb}{0.6,0.1,0.1}

\lstset{%configuration de listings
language=Java,%
float=hbp,%
basicstyle=\ttfamily\small, %
identifierstyle=\color{colIdentifier}, %
keywordstyle=\color{colKeys}, %
stringstyle=\color{colString}, %
commentstyle=\color{colComments}, %
columns=flexible, %
tabsize=2, %
frame=trBL, %
frameround=tttt, %
extendedchars=true, %
showspaces=false, %
showstringspaces=false, %
numbers=left, %
numberstyle=\tiny, %
breaklines=true, %
breakautoindent=true, %
captionpos=b,%
xrightmargin=-0.1mm, %
xleftmargin=-0.1mm
}


%\parindent 0.6cm
%\setlength{\parskip}{0.5em plus 0.2em minus 0.2em}

\title{Rapport Projet domotique}
\author{Frédéric \textsc{Bouvet} \and Anthony \textsc{Caillaud} \and Hervé
  \textsc{Esteguet} \and Alexandre \textsc{Garnier} \and Oumar \textsc{Gueye}}
\date{\today}
\ifpdf
\pdfinfo{
/Author (Anthony Caillaud Alexandre Garnier Frédéric Bouvet Oumar Gueye Hervé
Esteguet)
/Title (Rapport Projet domotique)
/Subject (Rapport Projet domotique)
/Keywords ()
/CreationDate (D:20100329212218)
}
\fi


\newcommand{\HRule}{\rule{\linewidth}{0.5mm}}
\newcommand{\emphbf}[1]{\textbf{\emph{#1}}}
\newcommand{\nlink}[2]{\href{#1}{\small{\underline{\textcolor{Blue}{#2}}}}}
\newcommand{\link}[1]{\nlink{#1}{#1}}
\newcommand{\SCA}{\emph{SCA}}
\newcommand{\BPEL}{\emph{BPEL}}
\newcommand{\WSDL}{\emph{WSDL}}
\newfloat{code}{H}{cod}[section]
\floatname{code}{Snippet}

\begin{document}

%% Puces au lieu de tirets dans les listes:
%\renewcommand{\labelitemi}{\textbullet}
%\renewcommand{\labelitemii}{\textbullet}
%\renewcommand{\labelitemiii}{\textbullet}

%\input{title.tex}
\maketitle

\clearpage
\tableofcontents
\clearpage

\section*{Introduction}
\addcontentsline{toc}{section}{Introduction}

Dans le cadre du projet de fin d'études, nous avons eu le choix entre deux
sujets correspondants au parcours Génie Logiciel.
Notre groupe abordera donc un projet dont le thème est celui de la simulation
d'Intelligence Ambiante.\\

L'intelligence Ambiante~\cite{intel_ambiante} est une notion informatique mettant en
œuvre quatre éléments de base.

Le premier correspond à la capacité pour l'utilisateur d'interagir avec
différents appareils interconnectés.
Le second représente la faculté du système à connaître le contexte d'usage pour
une application.
C'est-à-dire le fait de connaître la présence et la position des appareils et
personnes à l'aide de capteurs.
Le troisième élément définissant l'Intelligence Ambiante est que l'accès aux
différents services doit s'effectuer le plus naturellement possible
contrairement aux interfaces traditionnelles (fenêtres, icônes, menus, \ldots).
Le dernier est la capacité du système à s'adapter dynamiquement aux situations
grâce à une approche d'intelligence artificielle.\\

L'objectif de ce projet est de pouvoir simuler un environnement d'intelligence
ambiante appliqué à la domotique.

Notre rôle est donc de concevoir un système intelligent intégré dans un
environnement pouvant répondre aux besoins de ses utilisateurs.

Ce système composé de plusieurs services et d'objets hétérogènes de descriptions
différentes se chargera de fournir à l'utilisateur le meilleur service et devra
pouvoir s'auto-configurer en fonction du contexte de l'utilisateur et de ses
besoins.

La domotique~\cite{domotique} est l'une des applications les plus connues
dans le domaine de l'intelligence ambiante. La correspondance entre le cas particulier de la
domotique et le cas général des environnements d'intelligence ambiante est:
\begin{itemize}
  \item la maison représente l’environnement;
  \item les différents appareils de la maison correspondent aux objets
    hétérogènes;
  \item les habitants de la maison  représentent les utilisateurs;
  \item Le système domotique représentera  le système intelligent.
\end{itemize}

Des offres de la domotique  existent déjà sur le marché, cependant la mise en
œuvre de ces systèmes demande l'intervention d'un technicien qui programme à
l'avance les possibilités de coordinations en fonction des exigences du
propriétaire de la maison et des appareils présents.

Ces offres existantes ont pour inconvénients d'être dépendantes de l'intervenant
et d'avoir une configuration limitée.
C'est-à-dire  que le système ne pourra détecter la présence ou l'ajout d'un
nouvel appareil dans la maison qu'après intervention d'un technicien.

La domotique que nous allons développer résoudra les défauts des systèmes
existants en apportant un certain dynamisme et une indépendance vis-à-vis du
système et pourra se reconfigurer en cas de présence ou de retraits d'appareils.

Notre système s'adaptera aussi en fonction du contexte des habitants (priorités,
positions) et de la qualité des ressources de la maison.

Il se chargera aussi de toute la gestion des appareils de la maison, de leur
coordination ainsi que de leur configuration.\\

Pour mettre en place ce système, nous avons choisi d'utiliser une architecture
orientée service. Dans ce type d'architecture, chaque ressource (télévision,
microphone, lecteur, \ldots) est assimilée à un service. De plus, on peut
réaliser une combinaison de ces ressources qui nous a permis de mettre en place
nos scénarios, c'est ce qu'on appellera la composition de services. Enfin, une
combinaison de ressources peut être vu comme une ressource à part entière
englobant cette combinaison. Dans le cadre d'une architecture orientée service,
cette ressource englobant une combinaison de plusieurs autres sera nommée
service composite.\\

Pour aboutir à une application fonctionnelle, notre démarche s'est articulée en
plusieurs étapes.
Tout d'abord, nous avons étudié un article traitant de la mise en place d'un
métamodèle du service composite, qui réifie une composition de services en
service à part entière.
Puis, nous avons écrit différents scénarios liés à la domotique avant d'en
effectuer une projection sur le métamodèle.
Ensuite, nous avons effectué des recherches sur les technologies existantes nous
permettant d'implanter ce que nous avions conçu et spécifié.
Une fois que le choix de la technologie utilisée a été fait, nous avons commencé
à implanter une solution.

Ce rapport constitue donc un compte-rendu du travail effectué pour la
réalisation de ce projet. Dans un premier temps, l'étude du métamodèle du
service composite sera présentée dans la section \ref{analyseMM}. Puis, nous
avons mis en place des scénarios explicités dans la section
\ref{scénarios_domotique}. Ensuite, l'architecture de notre application
sera décrite dans la section \ref{archi_appli}. Dans la section
\ref{diagrammes}, les intéractions entre composants du métamodèle seront
montrées grâce à différents diagrammes. La question du choix
des outils permettant l'implémentation de notre solution sera ensuite abordée
dans la section \ref{sec:choix_outils}. Enfin, tout ce qui concerne le
développement du projet, ses restrictions et les difficultés rencontrées sera
traité dans les sections \ref{Implementation} et \ref{difficultes}.


\section{Analyse du Métamodèle de Service Composite}
\label{analyseMM}

Dans le cadre de ce projet, nous avons immédiatement compris que sa
réalisation sera faite à l'aide de services et plus partiulièrement la
composition de services.
Nous allons donc commencer par faire un bref rappel sur les architectures
orientées services, puis nous expliquerons ce que nous a apporté l'étude du
métamodèle de service composite.

\subsection{Architecture Orientée Service}

Le principe d'Architecture Orientée Service(AOS) est un paradigme pour
l'organisation et l'utilisation de fonctionnalités distribuées pouvant être sous
le contrôle de propriétaires différents~\cite{oasis}.

En effet, une personne peut avoir besoin d'un service déjà existant, créé et
offert par quelqu'un d'autre. Au niveau de l'informatique distribué, une
application peut avoir besoin de données fournies par une autre. L'approche AOS
est donc une réponse à ce problème permettant de fournir un framework pour
relier les besoins et les services offerts. Enfin, il permet aussi de combiner
ces différents services afin de répondre aux besoins des utilisateurs.\\

Dans un programme suivant ce type d'architecture, le traitement est décomposé en
services qui représentent chacun une ressource. Ces ressources sont autonomes,
configurables, composables et réutilisables; ce qui donne à l'approche AOS une
valorisation de la réutilisation, de la croissance et de l'intéropérabilité. Un
service est un composant autonome qui ne dépend d'aucun contexte ou service
externe. Une architecture orientée services consiste donc essentiellement en une
collection de services qui interagissent et communiquent entre eux.

Dans ce type d'architecture, une mécanique dynamique est mise en place afin de
trouver et utiliser les services dont nous avons besoin. Cette mécanique repose
sur deux mécanismes qui sont la publication de services et la composition de
services. Pour cela, chaque service est lié à une description. En ce qui
concerne la publication, cela consiste en l'enregistrement du service et de sa
description dans un annuaire de services qui référence l'ensemble des services
disponibles. On peut alors publier des services sur ces annuaires ou en obtenir
à partir des leurs descriptions. La composition de service, quant à elle, peut
être vue comme un ensemble de trois étapes successives permettant de combiner
des services séléctionnés selon des critères et des préférences utilisateurs.
Ces étapes sont la découverte des services nécessaires, la séléction des
services parmi ceux découverts que l'on souhaite utiliser et enfin la
combinaison de ces services pour répondre aux besoins attendus. La notion de
description d'un service sera ici utilisée comme support au mécanisme de
découvertes et sélection d'un service.


\subsection{Étude du métamodèle}

Les cours que nous avons suivis lors du module de Services nous ont donc été
utiles.
Cependant, ceux-ci n'étaient pas suffisants car le projet nécessite des
connaissances plus approfondies.
Nous avons donc étudié l'article de
Hock-koon \& Oussalah~\cite{MMServiceComposite} concernant la composition de
services par Méta-Modélisation d'un Service Composite.
Cet article, datant de 2010 et ayant évolué depuis, nous servira de base.
Par la suite, nous avons travaillé sur une version plus récente du métamodèle.\\

Dans un premier temps, nous allons présenter le métamodèle \ref{MMSvcCompos} sur
lequel nous nous sommes appuyés pour faire le lien avec notre projet. Ce lien
sera ensuite présenté dans la section \ref{lien_mm_scenar}.

\subsubsection{Vue Globale}

\begin{figure}[htb]
  \centering
  \includegraphics[width=\textwidth]{images/mm_service_composite.png}
  \caption{Métamodèle du Service Composite}
  \label{MMSvcCompos}
\end{figure}

On peut tout d'abord observer que dans cet article un Service Composite est
considéré comme un service à part entière.
Ensuite, celui-ci est décrit comme étant composé d'un ensemble de services
métiers et d'un ensemble de services gestionnaires.

Les services métiers représentent les services fonctionnels (la diffusion d'un
son, \ldots) ou non fonctionnels (sécurité, \ldots) répondant aux besoins de
l'architecte. Ces services fournissent leurs fonctionnalités sans connaissance
globale sur la composition. L'ensemble de ces services constitue le Service
Composite Métier (SCM).

Les services gestionnaires, quant à eux, sont spécialisés dans la gestion de la
composition.
Ils gèrent les autres services constituants et ont une connaissance de la
composition.
L'ensemble de ces services est regroupé dans le Gestionnaire de Service
Composite (GSC).

Une des contributions de cet article est l'explication des caractéristiques
de gestion attendues d'un service composite ainsi que la définition des
interdépendances entre les rôles des gestionnaires.
Pour bien comprendre l'apport du GSC, nous allons décrire plus précisément les
différents gestionnaires le constituant.\\

\subsubsection{Gestionnaire de Service Composite}

\begin{figure}[htb]
  \centering
  \includegraphics[width=\textwidth]{images/GSC.png}
  \caption{Métamodèle du GSC}
  \label{MMGSC}
\end{figure}

Comme le montre la figure \ref{MMGSC}, le GSC est composé dans cet article de
trois services gestionnaires.
Ces trois services sont le gestionnaire de collaboration, le
gestionnaire d'adaptation et le gestionnaire de contexte.

Le gestionnaire de collaboration, à l'aide d'un schéma mis à jour, apporte au
composite la capacité à connaître les services métiers à invoquer et
la coordination de ces invocations.

Le gestionnaire d'adaptation, quant à lui, va permettre l'auto composition qui
est un des points important proposé par ce métamodèle. Cela correspond à la
capacité du composite à modifier son architecture et à prendre en compte ces
modifications dans ses logiques de compositions. Ce gestionnaire va pour cela se
baser sur un moteur de découverte et sélection de services.

Enfin, le gestionnaire de contexte permet la persistance des données pouvant
être utilisées par le service composite.

Grâce à ce métamodèle, nous avons pu mettre en place une architecture adaptée à
notre projet.

\section{Scénarios dans la domotique}
\label{scénarios_domotique}

Dans cette section, nous allons donc présenter les différents scénarios que nous
avons choisis de mettre en place pour ce projet. Ils ont induit certaines
contraintes qui seront explicités par la suite. Elles peuvent être de deux types
différents en fonction du nombre d'utilisateurs; des contraintes simples et des
contraintes concernant le multitenant. Une architecture multitenant fait qu'une
seule instance de l'application est adaptée aux besoins de tous les
utilisateurs, de manière individualisée. Cette personnalisation concerne aussi
bien l'interface que les règles métier ou les processus.

\subsection{Écoute de musique et vidéo-conférence}

Dans le cadre de l'intelligence ambiante et plus particulièrement de la
domotique, nous avons choisi de mettre en place pour ce projet deux types de
scénarios. Ces deux scénarios nous permettent de bien mettre en place le système
de reconfiguration en cas de panne ou de dysfonctionnement d'un appareil.
Dans les deux cas, la maison représente l'environnement et les
appareils tels que les microphones, les lecteurs, les haut-parleurs ou
encore la caméra correspondront aux objets hétérogènes intéragissant
avec les utilisateurs. Voici une description plus détaillé des
scénarios mis en œuvre dans notre simulation:

\begin{enumerate}
  \item \emphbf{Scénarios d'écoute de musique:}
    \begin{itemize}
      \item Un scénario où un résident veut écouter de la musique sur
        haut-parleur et désire que cette musique l'accompagne à travers ses
        déplacements dans les différentes pièces de la maison.
        L'utilisateur va donc exprimer oralement la musique qu'il souhaite
        entendre via l'interface de communication homme-machine disponible la
        plus proche.
        Le système va rechercher à travers tous les appareils stockant de la
        musique celui qui possède la chanson voulue.
        La musique sera jouée puis le son diffusé dans la salle où est
        situé l'utilisateur.
      \item Un scénario où un résident demande la lecture d'une musique sur
        haut-parleur alors qu'il y'a la présence d’un autre résidant ayant une
        priorité plus élevée et souhaitant écouter une autre musique via le même
        haut-parleur.
    \end{itemize}
    Ces deux scénarios mettront en collaboration 3 ressources de la maison:
    \begin{itemize}
      \item l'élément capable de récupérer le choix de l'utilisateur.
      \item l'appareil de lecture de la musique.
      \item l'appareil de diffusion du son.
    \end{itemize}
  \item \emphbf{Scénarios vidéo-conférence:}
    le résident est entrain d'écouter de la musique, il reçoit un appel de
    vidéo-conférence. il désire mettre en attente la musique et répondre à
    l'appel de vidéo-conférence.
    À la fin de la vidéo-conférence, il réactive la musique.
    Ce scénario définira  la collaboration de 5 ressources:
    \begin{itemize}
      \item l'appareil de réception-émission de la communication.
      \item l'appareil de diffusion de l'image.
      \item l'appareil de diffusion du son.
      \item l'appareil de récupération de l’image.
      \item l'appareil de récupération du son.
    \end{itemize}
\end{enumerate}

\subsection{Contraintes simples}
Ces scénarios, une fois bien définis, nous ont incité à se poser de nombreuses
questions et à faire des choix. Ces choix seront donc représentés dans notre
projet sous forme de contraintes contextuelles. Celles-ci sont donc expliquées
plus précisément dans la liste suivante :

\begin{itemize}
  \item \emphbf{la localisation de l'utilisateur:}
    les déplacements de l'utilisateur à travers les pièces vont diriger quelle
    interface homme-machine (microphone) et quel appareil de diffusion du son
    doivent être utilisés.
    Le système doit être capable d'arrêter la diffusion du son dans la salle
    précédente tout en démarrant la diffusion dans la nouvelle pièce. Le
    changement d'interface homme-machine doit être transparent pour
    l'utilisateur qui doit toujours être capable de modifier le choix de la
    musique diffusée.
  \item \emphbf{la qualité des appareils:}
    le système devra chercher à offrir en priorité le meilleur service possible,
    que ce soit dans la portée de réception du microphone pour éviter les
    déplacements de l'utilisateur, que dans la qualité du son diffusé par les
    différents haut-parleurs ou celle des lecteurs.
  \item \emphbf{la disponibilité des appareils:}
    au moment de la demande de collaboration, les appareils pouvant remplir les
    rôles nécessaires ne sont pas forcément disponibles ou peuvent devenir
    indisponibles pendant leur utilisation.
    Par exemple ils peuvent être déjà utilisés par un autre scénario ou tout
    simplement tomber en panne.
    Le système doit essayer de trouver une alternative, si elle existe, pour
    assurer le fonctionnement tout en respectant les contraintes minimales.
\end{itemize}

\subsection{Contraintes sur le multitenant}

Ensuite, nous nous sommes rendus compte que la gestion du multitenant
allait être nécessaire. En effet, plusieurs scénarios peuvent avoir lieu en
même temps et plusieurs clients peuvent aussi vouloir exécuter un même scénario.
Dans ces deux cas, la gestion du multitenant s'avère obligatoire afin de gérer
les différentes priorités. Pour cette gestion, nous avons donc mis en place
certaines contraintes décrites ci-dessous.

\begin{itemize}
  \item \emphbf{l'interaction entre différents scénarios en exécutions:}
    cette interaction peut être la cause de changements d'état de disponibilité
    des ressources en cours d'utilisation ou utilisables du point de vue du
    scénario.
    En effet, il peut y avoir une hiérarchie dans l'importance des scénarios qui
    va définir des priorités d'exécution.
    Une priorité temporelle (le premier arrivé est le premier servi) ou relative
    (un scénario est plus important que l'autre et s'accaparera automatiquement
    la ressource, typiquement un scénario de diffusion de message d'alerte par
    rapport à notre diffusion de musique).
    Ces priorités temporelles et relatives liées aux scénarios vont être
    associées à une hiérarchisation entre les utilisateurs respectifs des
    scénarios en concurrence.
  \item \emphbf{l'interaction entre les différents utilisateurs:}
    certains utilisateurs peuvent avoir une priorité plus importante où les
    scénarios les concernant seront favorisés et donc causer des
    indisponibilités de ressources pour les autres.
    L'exemple le plus représentatif qui sera modélisé est la priorité entre
    parents et enfants.
    Cette priorité peut aussi inclure des informations relatives à la pièce où
    l'on se trouve. Par exemple, dans sa chambre l'enfant peut avoir une
    priorité supérieure.
    Ce principe va être généralisé à une notion de propriété d'un utilisateur
    par rapport à une salle ou une ressource (un enfant et sa chaine Hi-Fi).
    Le système doit aussi être capable de gérer des utilisateurs inconnus,
    c'est-à-dire non enregistrés et arrivant pour la première fois dans
    l'environnement.
  \item \emphbf{le multitenant:}
    en parallèle à la gestion de différents scénarios et différents utilisateurs
    certains services peuvent être multitenants, c'est à dire capables de gérer
    plusieurs clients en même temps.
    Pour notre simulation ce sera le cas dans l'interaction avec le microphone
    qui va récupérer le son émis par plusieurs personnes. Le système devra être
    capable d'identifier ces personnes et de les associer aux bons scénarios.
    Un élément de reconnaissance vocale devra être correctement spécifié dans la
    collaboration entre les ressources.
\end{itemize}


\section{Architecture de l'application}
\label{archi_appli}

Nous allons dorénavant présenter l'architecture mise en place afin de satisfaire
à la problématique posée.

En partant du métamodèle vu en figure \ref{MMSvcCompos}, nous proposerons tout
d'abord une composition de services tenant compte de cette spécification.

Ensuite nous amènerons une première conception des stratégies d'orchestration
qui devrait apporter une solution efficace à la gestion d'une telle vision de la
composition de services dans un contexte global.

\subsection{Services composites}
\label{lien_mm_scenar}

Nous aborderons ici la conception de services composites répondant aux attentes
et contraintes soulevées par les scénarios présentés dans la section
\ref{scénarios_domotique}.
Nous nous attarderons plus spécifiquement sur l'exemple de la lecture d'une
musique tout en faisant le parallèle avec la gestion de vidéoconférences, les services
métiers et leur orchestration étant relativement similaires dans les deux cas.

Les deux services, qui au fur et à mesure de la conception, se sont imposés
comme étant des services composites sont le service de lecture de musique et le
service d'exécution. Le service de lecture de musique permet à l'utilisateur qui
en fait la demande via un microphone de lire une musique sur un lecteur et de
l'écouter sur le haut-parleur le plus près de sa position. Le service
d'éxecution permet, quant à lui, de trouver les appareils tels que le lecteur ou
encore le haut-parleur permettant cette écoute de musique. Le service de lecture
s'imposait comme un composite car celui-ci devait utiliser les services de
position, de découverte et séléction ainsi que celui d'exécution. Le service
d'exécution est appelé par le service de lecture de musique et nécessite d'être
composé du service de position, du service de lecteur et du service de
haut-parleur permettant de trouver ces appareils.

\subsubsection{Service de lecture de musique}

\begin{figure}[htb]
  \centering
  \includegraphics[width=\textwidth]{images/ServiceLectureMusique.png}
  \caption{Service de lecture de musique}
  \label{fig:ServiceLectureMusique}
\end{figure}

La figure \ref{fig:ServiceLectureMusique} présente l'instanciation d'un service
composite tel que vu en figure \ref{MMGSC}, dans le cadre de la lecture
d'une musique.

Le processus de lecture d'une musique est explicité par le diagramme reprenant
le formalisme BPEL dans le gestionnaire de collaboration.\\

Il se définit comme suit:
\begin{itemize}
  \item lors de la demande de lecture de musique d'un client,
    la position (\emph{ie} la pièce dans laquelle il se trouve) et
    l'identifiant de ce dernier sont récupérés;
  \item ensuite, sa demande est traîtée, c'est à dire que vont être trouvés
    un lecteur et un haut-parleur correspondant respectivement à la musique
    demandée et à la position du client;
  \item dès lors, le service d'exécution va se charger d'instancier l'exécution
    de la commande, à savoir lire la musique demandée dans la pièce où se trouve
    le client;
  \item enfin, une routine est lancée afin de gérer le déplacement du client au
    sein de la maison.\\
\end{itemize}

Pour ce faire, il met en œuvre les services métier suivant:
\begin{itemize}
  \item \emphbf{Position+id}: se charge de récupérer la position et l'identifiant
    du client à l'origine de la commande;
  \item \emphbf{Découverte/Sélection}: à ne pas confondre avec le
    \emph{gestionnaire} de découverte et sélection, celui-ci va se charger
    d'aller découvrir les lecteurs et haut-parleurs satisfaisant à la commande
    et à la position du client, pour en choisir un couple (le critère de
    sélection est laissé à la discrétion du service métier);
  \item \emphbf{Exécution}: permet ici l'instanciation de la lecture de la
    musique demandée; dans un contexte plus large, il doit permettre l'exécution
    de tout type de commande.\\
\end{itemize}

Dans le cas d'une vidéoconférence, on retrouve les mêmes services métiers,
et la seule différence au niveau de l'orchestration va se situer au niveau des
appareils à trouver, à savoir télévision, microphone et caméra plutôt que
lecteur et haut-parleur.

\subsubsection{Service d'exécution}

Dans le cadre de la composition de services, un des objectifs est clairement la
réutilisabilité de services composites en tant que services métier (voire de
services gestionnaire) au sein d'autres services composites.

Dans cette optique, il nous est apparu que le service d'exécution --- un des
services métier récurrent dans la gestion des commandes, tel que l'illustre la
figure \ref{fig:ServiceLectureMusique} --- gagnait à être lui-même considéré
comme un service composite.\\

\begin{figure}[htb]
  \centering
  \includegraphics[width=\textwidth]{images/ServiceExecution.png}
  \caption{Service d'exécution}
  \label{fig:ServiceExecution}
\end{figure}

Ainsi, la figure \ref{fig:ServiceExecution} illustre la spécification que nous
avons faite du service d'exécution, dans le cadre de la lecture d'une musique.
L'idée étant ici d'instancier un couple (lecteur, haut-parleur) afin de pouvoir
exécuter la musique souhaitée depuis le lecteur vers un haut-parleur à proximité
du client, le gestionnaire de collaboration illustre cette construction.\\

En ce qui concerne les services métiers, nous avons ici:
\begin{itemize}
  \item \emphbf{Lecteur}: se charge de trouver un lecteur en fonction de la
    musique souhaitée;
  \item \emphbf{Haut-parleur}: trouve un haut-parleur proche du client;
  \item \emphbf{Position}: donne la position du client, permet
    d'assurer le bon fonctionnement du gestionnaire d'adaptation, qui dès lors
    s'aura s'adapter à chaque déplacement du client ; cela permet aussi une
    meilleure résistance aux pannes du haut-parleur, dès lors le service
    d'exécution saura chercher un haut-parleur de remplacement, ce grâce à la
    position du client.\\
\end{itemize}

Pour ce qui est de la vidéo-conférence, la construction d'un couple instanciable
reste là encore très similaire, les services métier \emph{Lecteur} et
\emph{Haut-parleur} seront remplacés respectivement par des services
\emph{Microphone+caméra} et \emph{Télévision}.


\subsection{Stratégies d'orchestration}
\label{subsec:strategie_orchestration}

Au cours de la conception de notre solution, nous nous sommes rendus compte que
l'orchestration des services dans le cadre des deux scénarios présentaient des
similarités. Ainsi, sur les exemples vus précédemment, à savoir la lecture d'une
musique ou la gestion d'une vidéo-conférence, on retrouve dans les deux cas
l'appel à deux services métiers similaires sur bien des aspects, à savoir les
services de découverte \& sélection, et d'exécution.\\

Dès lors, dans un soucis d'optimisation et de flexibilité vis-à-vis
du gestionnaire d'adaptation, nous avons cherché à apporter à la spécification
BPEL du gestionnaire de collaboration la notion de généricité et d'héritage.
L'avantage ici est de proposer au développeur devant répondre aux attentes d'un
système de domotique établi une base de travail par le biais de BPEL dont il
pourra hériter dans la conception d'un service composite.\\

Le gestionnaire d'adaptation permettant le remplacement dynamique de services,
qui ne sont plus disponibles ou défaillants, utilise un mécanisme de
découverte/séléction. De plus, comme on l'a vu dans la section \ref{analyseMM},
un service est composé de fonctionnalités et d'une description. C'est grâce à
cette description que nous effecturons la découverte dynamique.

En outre, afin de lier ce modèle au gestionnaire d'adaptation afin qu'il puisse
tirer partie des avantages apportés, une convention de nommage nous est apparue
nécessaire, ce sur quoi nous reviendrons une fois les relations d'héritage
établies.

\subsubsection{Relations d'héritage et d'instanciation entre les BPEL}

\begin{figure}[htb]
  \centering
  \includegraphics[width=\textwidth]{images/BPELRelations.png}
  \caption{Relations entre les niveaux d'abstraction des BPEL}
  \label{fig:BPELRelations}
\end{figure}

La figure \ref{fig:BPELRelations} illustre les différents niveaux d'abstraction
de BPEL et les relations qui existent entre ceux-ci; dans un soucis de clarté,
nous avons repris une partie du vocabulaire Java:

\begin{itemize}
  \item \emphbf{niveau sémantique abstrait}: ne permet de définir que les
    relations entre services, et en tant que tel ne peut être instancié; peut
    cependant être implémenté en un BPEL concret;
  \item \emphbf{niveau syntaxique concret}: propose un BPEL instanciable; étant
    directement instanciable, il ne peut être à nouveau implémenté, cependant,
    un BPEL abstrait peut l'étendre afin de lui ajouter des fonctionnalités;
  \item \emphbf{instance}: instanciation d'un BPEL concret, ne peut être ni
    implémenté, ni étendu, ni instancié ; c'est le seul niveau qui soit
    exécutable.\\
\end{itemize}

Ainsi, si on reprend en partie les concepts apportés par la gestion des
interfaces et classes Java (respectivement niveaux abstrait et concret), des
différences existent toutefois, notamment en ce qui concerne la notion
d'extension.
En effet, elle se définit ici du niveau concret vers le niveau
abstrait.
En outre, elle ne permet que d'ajouter des services au sein du BPEL, en aucun
cas elle ne vient modifier le fonctionnement du BPEL qu'elle étend. En tant que
tel, la partie étendue reste concrète, comme le montre le diagramme de la figure
\ref{fig:BPELRelations}.\\

Outre le fait qu'on retrouve en partie le formalisme Java, viennent aussi les
avantages liés aux notions d'héritage et d'instanciation dans le paradigme
Objet, notamment la dynamicité apportée par ces concepts.

L'instanciation d'une part permet de bien séparer la définition et l'exécution
d'un schéma de collaboration, de telle sorte que celui-ci pourra dès lors se
voir spécialisé d'autre part parmi les deux relations d'héritage spécifiées.

\subsubsection{Convention de nommage des services: les ontologies}

Afin de proposer un cadre au fonctionnement des gestionnaire d'adaptation au
sein des services composites, il nous est vite apparue la nécessité de proposer
une convention de nommage des services. Le but ici est de permettre au
gestionnaire d'adaptation d'aller trouver des services non seulement en fonction
de la spécification attendue, mais également de la description du service, et
c'est là qu'interviennent les ontologies.

Ces ontologies permettent donc de faire le lien entre nos services et les
ressources exploitables du système. Par exemple, dans le cadre de notre scénario
d'écoute de musique, le service de position, le service de lecteur et le service
d'exécution seront respectivement décrits par les ontologies "position",
"découverte/sélection lecteur" et "exécution audio".

Dans cette optique, en prenant compte la notion d'héritage vue précédemment,
nous avons choisi de refléter la hiérarchie qui en découle au sein des
ontologies. Lors de l'établissement d'une telle convention de nommage, celle-ci
se doit naturellement d'être claire, concise et explicite, afin d'une part
d'éviter de se retrouver avec des services utilisés à tort, d'autre part de
rester compréhensible vis-à-vis des utilisateurs.\\

Compte tenu de toutes ces contraintes, la figure \ref{fig:ontologies} présente
les ontologies que nous avons établies dans le cadre d'un système de domotique.

\begin{figure}[htb]
  \centering
  \fbox{\begin{minipage}{\textwidth}
    \begin{itemize}
      \item \emphbf{id}: retourne l'id d'un utilisateur quand celui-ci fait appel
        au système;
      \item \emphbf{position}: retourne la position d'un utilisateur en fonction
        de son id;
      \item \emphbf{découverte/sélection}: trouve certaines informations en
        fonction de divers paramètres d'entrée;
        \begin{itemize}
          \item \emphbf{découverte/sélection diffusion}: trouve un périphérique
            de diffusion en fonction de la position de l'utilisateur;
            \begin{itemize}
              \item \emphbf{découverte/sélection HP}: trouve un haut-parleur;
              \item \emphbf{découverte/sélection TV}: trouve une télévision;
            \end{itemize}
          \item \emphbf{découverte/sélection lecteur}: trouve un lecteur en
            fonction du titre et de l'id;
          \item \emphbf{découverte/sélection caméra}: trouve une caméra en
            fonction de la position de l'utilisateur;
        \end{itemize}
      \item \emphbf{exécution}: just do it!;
        \begin{itemize}
          \item \emphbf{exécution audio}: diffusion du titre depuis le lecteur
            sur le haut-parleur;
          \item \emphbf{exécution vidéoconf}: émission du pair sur la télévision
            et démarrage de la caméra.
        \end{itemize}
    \end{itemize}
  \end{minipage}}
  \caption{Ontologies liées à la domotique}
  \label{fig:ontologies}
\end{figure}

\section{Interactions entre composants du métamodèle}
\label{diagrammes}

Nous allons présenter dans cette section, l'interaction entre le système et
l'utilisateur.
Pour cela, nous avons choisi deux types de représentation d'interactions:

\begin{itemize}
  \item \emphbf{le diagramme de séquence:}
    Ce diagramme montre non seulement l'interaction entre l'utilisateur et la
    façade du système mais aussi les différents interactions entre composants du
    système et les différents composants intervenant pour un scénario donné.
    Il illustre aussi l'ordre d'appel de ces composants et la dynamique du
    système.
  \item \emphbf{le diagramme d'états/transitions:}
    Ce diagramme montre les différents états existants pour chaque ressource du
    système et les différents événements provoquant le changement d'état d'une
    ressource du système.
    C’est une représentation d'automates déterministes différente du diagramme
    de séquence.
    Il a pour avantage de montrer les états du système et les facteurs qui
    provoquent les changements d'états.
\end{itemize}

\subsection{Diagramme de séquence du système}

Nous allons présenter dans cette partie des scénarios du système et donner les
diagrammes de séquence correspondants.

\subsubsection{Scénario 1}

C'est un scénario d'une demande de lecture de musique d'un résident qui se
déroule normalement sans conflit.
Il se déroule comme suit:

Un résident envoie la commande «~lecture~» au système en passant le titre de la
musique comme paramètre.
L’envoie de la commande se fait par voie orale et le résident doit se trouver
dans l'environnement (maison).
le système réagit comme suit:

\begin{itemize}%•
  \item La commande est interceptée par le Service Composite Lecture (SC
    Lecture).
  \item Celui ci émet une requête au Service Composite Métier (SCM) en lui
    demandant la position du résident (getPosId()).
    Il stocke la réponse (position) dans la variable posID.
  \item Après cette procédure le SC lecture demande au SCM de trouver un
    lecteur contenant le titre demandé.
    Le SCM délègue cette demande au service découverte et sélection
    (Devc+selection Lecture).
    Un lecteur lec lui sera retourné.
  \item SC Lecture recherche aussi un haut-parleur (HP) se trouvant à la
    position posid au service Devc+selection Lecture par l'intermédiaire du SCM.
    Un haut-parleur HP lui est renvoyé.
  \item par l'intermédiaire de SCM, le SC Lecture transmet le couple (lec,hp)
    au Gestionnaire de Service Composite qui se chargera de leurs instanciations
    et de leur collaboration puis transmet au service d'exécution lecture(Exec
    Lecture) le résultat.
  \item Enfin le SC lecture envoie le contexte de l'utilisateur au gestionnaire
   de contexte client (GCL Lecture) qui le rendra persistant.
\end{itemize}

La musique est diffusée au client.

Le diagramme de séquence du scénario correspond à la figure \ref{d1}.

\begin{figure}[htb]
  \begin{center}
  \includegraphics[width=\textwidth]{images/ScenarioLectureMusique.png}
  \caption{Scénario lecture musique }
  \label{d1}
  \end{center}
\end{figure}

Le diagramme de séquence d'instanciation du lecteur et du haut-parleur
correspond à la figure \ref{d11}.

\begin{figure}[htb]
  \begin{center}
  \includegraphics[width=\textwidth]{images/ScenarioExecutionMusique.png}
  \caption{Scénario  d'instanciation lecteur lec et haut-parleur hp  }
  \label{d11}
  \end{center}
\end{figure}

\newpage
\subsubsection{Scénario 2}

Ce scénario correspond a une modification de l'état d'une  musique en cours
d'exécution.
Le résident envoie une type de commande au système.
La commande «~cmd~» peut prendre les valeurs suivantes:

\begin{itemize}
  \item \emph{arret  }
  \item \emph{avance}
  \item \emph{recule}
  \item \emph{pause etc...}
\end{itemize}

\begin{itemize}%•
  \item Le SC Lecture intercepte la commande envoyée
  \item Il recherche le lecteur exécutant la musique en passant l'identifiant
    (Id) du résident:
    cette recherche est faite par l'appel de la fonction cherchLect(id) du
    gestionnaire de service composite (GSC), le GSC délègue  cet appel au
    gestionnaire de contexte client(GCL) qui retourne le lecteur «~lec~».
  \item Et enfin l'exécution  de la commande  «~cmd~» au lecteur  «~lec~»:
    Elle est faite en passant les paramètres au service composite d’exécution
    (SC Exec), qui les transmet au service lecteur d'exécution (Lecteur Exec).
\end{itemize}

Le diagramme de séquence du scénario correspond à la figure \ref{d2}.

\begin{figure}[htb]
  \begin{center}
  \includegraphics[width=\textwidth]{images/ScenarioCommandeMusique.png}
  \caption{Scénario de changement d'une musique en cours d'exécution }
  \label{d2}
  \end{center}
\end{figure}

\subsubsection{Scénario 3}

Ce troisième scénario correspond au cas où un résident X demande la lecture
d'une musique dans un emplacement où la ressource commune haut-parleur (HP) est
en cours d'utilisation par un autre résident Y.

Le résident X envoie la commande de lecture de musique en passant en paramètre
le titre de la musique.
Le SC Lecture reçoit la commande envoyée par le résident X et fait le traitement
suivant:

\begin{itemize}%•
  \item Il récupère la position de la personne X à travers le service métier
    (Pos + id Lecture) du service composite Lecture (SC Lecture).
  \item récupère sa priorité «~clid~» à partie du gestionnaire de contexte
    client (GSL lecture )
  \item Compare  sa priorité «~clid~» à celle de Y.
  \item Si sa priorité  est inférieure alors le système met en attente sa
    demande s'il reste dans cette position
  \item Sinon  le système exécute sa demande de lecture de musique
    correspondant au scénario 1.
\end{itemize}

Le diagramme de séquence du scénario correspond à la figure \ref{d3}.

\begin{figure}[htb]
  \begin{center}
  \includegraphics[width=\textwidth]{images/ScenarioConflitMusique.png}
  \caption{Scénario demande de lecture avec conflit }
  \label{d3}
  \end{center}
\end{figure}

\subsection{Les diagrammes d'états du système}

Nous présentons ci-dessous les diagrammes d'etats des ressources et services du
système pouvant changer d'etat qui sont:

\begin{itemize}
  \item \emph{haut-parleur (HP)}
  \item \emph{lecteur}
  \item \emph{service position}
  \item \emph{service d'execution}
\end{itemize}

\subsubsection{Diagramme d'états haut-parleur:}

Un haut-parleur quelconque se trouvant dans la maison est soit en diffusion soit
en arrêt.

Nous en déduisons qu’un haut-parleur ne prend que deux états («~en  diffusion~»
et «~libre~»).

Un haut-parleur passe de l'état «~libre~» à l’état «~en diffusion~» s'il
reçoit une commande de diffusion de son.
Il passe de l'état «~en diffusion~» à l'état «~libre~» dés qu'il reçoit une
commande d'arrêt de diffusion (stop).

Son état initial est «~libre~».
Son diagramme d'état correspond à la figure \ref{d4}.

\begin{figure}[htb]
  \begin{center}
  \includegraphics[width=\textwidth]{images/hp.png}
  \caption{diagramme d'état d'un haut-parleur }
  \label{d4}
  \end{center}
\end{figure}

\subsubsection{Diagramme d'état lecteur}

Un lecteur est soit en état libre («~libre~»), soit en état de lecture («~en
lecture~»), soit en état de pause («~en pause~»).

Le passage de l'état «~libre~» à l'état «~en lecture~» se fait après réception
d'une demande de lecture d'un titre se trouvant dans le lecteur.

La transition de l'état «~en lecture~» à l'état «~en pause~» est déclenchée par
la réception  de la commande «~pause~» envoyé par un résident.

La transition de l'état «~en lecture~» à l'état «~libre~» est créée par la
commande «~stop~» provenant d'un résident.

Enfin la transition de l'état «~en pause~» à l'état «~libre~» est créé aussi par
la commande «~stop~» provenant d'un résident.

La figure \ref{d5} est le diagramme d'état d'un lecteur.

\begin{figure}[htb]
  \begin{center}
  \includegraphics[width=\textwidth]{images/lect.png}
  \caption{diagramme  d'état d'un lecteur}
  \label{d5}
  \end{center}
\end{figure}

\subsubsection{Diagramme d'état du service d'exécution}

Le service d'exécution à deux états:

\begin{itemize}
  \item un état («~Au repos~»)  où il est au repos c'est-à-dire aucune instance
    en cours d'exécution.
  \item un  autre état  («~Construction de l'instance~») où il est en cours
    d'exécution d'une instance.
\end{itemize}

Il a deux transitions:

\begin{itemize}
  \item «~creeinstance~»: de l'état «~Au repos~» à  l'état «~Construction de
    l'instance~» déclenché par la réception du couple (lecteur,hp).
  \item «~Instance créer~»: de l'état «~Construction de l'instance~» à l'état
    «~Au repos~» déclenché après la fin de la phase de construction d’instance.
\end{itemize}

La figure \ref{d6} représente le diagramme d'état du service d'exécution.

\begin{figure}[htb]
  \begin{center}
  \includegraphics[width=\textwidth]{images/exec.png}
  \caption{diagramme  d'état du service d'exécution }
  \label{d6}
  \end{center}
\end{figure}

\newpage
\subsubsection{Diagramme d'état du service de position}

Le service de position a deux états:

\begin{itemize}
  \item «~Au repos~»: correspond à l'état ou il est au repos c'est à dire quand
    il n'est pas en recherche de position.
  \item «~en recherche de position~»: l'état ou il est en recherche de position.
\end{itemize}

Et deux transitions:

\begin{itemize}
  \item «~Recherche~»: de l'état «~Au repos~» à l'état «~en recherche de
    position~» causé par la recherche de la position d'un résidant identifié.
  \item «~Position trouvé~»: de l'état «~en recherche de position~» à l'état
    «~Au repos~» déclenché après la fin de la phase de recherche de position.
\end{itemize}

La figure \ref{d7} correspond au diagramme d'état du service de position.

\begin{figure}[htb]
  \begin{center}
  \includegraphics[width=\textwidth]{images/pos.png}
  \caption{diagramme  d'état du service de position }
  \label{d7}
  \end{center}
\end{figure}

\section{Choix des outils}%%A voir entre Hervé, Alexandre et Frédéric
\label{sec:choix_outils}
	Cette section explore les différentes possibilités disponibles pour la mise  en
oeuvre du métamodèle et des différents scénarios.

	La multitude de technologies présentes sur le marché incite à être
cohérent et prudent dans le choix des outils pour une réalisation aisée et efficace du travail demandé.

	De ce fait une étude comparative des différentes solutions a  parfois été nécessaire et
déterminant pour les choix.

	Dans un premier temps, les outils relatifs à la
phase de réalisation du métamodèle et de modélisation des scénarios seront
présentés; seront ensuite discutées, les possibilités d'implémentation et de
réalisation concrête.

\subsection{La phase de modélisation}
\label{subsec:choix_outils_modelisation}

Comme le montre les différents schémas présentés dans ce rapport, le modèle UML
(Unified Modeling Language) a été largement utilisé pour la description du
métamodèle et la compréhension des différents scénarios.
Cet outil possède une flexibilité de modélisation suffisante, mais aussi de la
maturité dû a son utilisation courante dans le domaine du génie logiciel entre
autres.
Il présente une grande variabilité de formalismes et de diagrammes permettant de
représenter les aspects du domaine étudié.

La liste suivante présente les différents diagrammes qui ont été utilisé dans ce
projet en justifiant leurs intérêts:

\begin{itemize}
  \item \emph{diagramme de classe:} utile pour la modélisation de la
    hiérarchie des services ainsi que des liens de compositions entre eux;
  \item \emph{diagramme d'état:} pour la modélisation de l'évolution de l' état
    des objets pendant leurs cycles de vie;
  \item \emph{diagramme de séquence:} pour mettre en évidence les interactions
    entre les différents services en vue de la réalisation d'un scénario précis;
  \item \emph{diagramme de composant:} permet de modéliser les interactions
    entre les différents composants du système.\\
\end{itemize}


Trois principaux outils de modélisation UML ont été utilisé au cours de ce
projet:

\begin{itemize}

  \item \emph{yEd:}~\cite{yed}

    un outil d' édition de toutes sortes de diagrammes, notamment des diagrammes
    UML; il est simple à prendre en main et permet d'obtenir assez efficacement
    le résultat souhaité;

\item \emph{ArgoUML:}~\cite{argouml}

    outil totalement réalisé en Java et spécialisé dans la modélisation UML; il
    offre une bonne perspective pour la réalisation des diagrammes d'états;

\item \emph{StarUML:}~\cite{staruml}

    logiciel opensource permettant de modéliser de manière flexible selon le
    formalisme UML; il est reservé au système d' exploitation Windows, et a été
    utilisé entre autre pour sa bonne présentation des diagrammes de séquences.

\end{itemize}

\subsection{La phase d'implémentation}
\label{subsec:choix_outils_implementation}

La meilleure des technologies pour l'implémentation doit être utilisable, et
doit pouvoir disposer de prérequis utiles à la gestion des besoins et objectifs
du métamodèle et des scénarios.

Comme besoins on peut citer:

\begin{itemize}
  \item \emph{construction de services:} on doit pouvoir déclarer des services
    et les exposer;
  \item \emph{la composition:} on doit pouvoir construire des services
    composites;
  \item \emph{l' interconnection:} on doit pouvoir de manière explicite définir
    les interactions entre les différents services qui composent le système;
  \item \emph{l'orchestration:} nécessaire pour la mise en oeuvre de la
    collaboration entre services (voir \ref{subsec:strategie_orchestration});
  \item \emph{l' instropection:} le système décrit doit pouvoir être monitoré
    pour pouvoir gérer l' adaptation;
  \item \emph{l' intercession:} on doit pouvoir modifier l' état du système
    pendant son exécution, ce qui permettra d'adapter lorsque ce sera
    nécessaire.
\end{itemize}

\subsubsection{Découverte des technologies existantes}

Les investigations sur les techniques et technologies présentes sur le marché
ont mis en évidence plusieurs possibilités, chacune d'elles ayant des
particularités qui lui sont propres:

\enumerate

  \item \emph{SCA Tools:}~\cite{scatools}

    Il s'agit un ensemble d'outils mettant en oeuvre le standard
    \emph{\textbf{S}ervice \textbf{C}omponent \textbf{A}rchitecture} proposé par
    l'Open SOA consortium.

    \emph{SCA} permet de décrire les composants d'un système ainsi les services
    qu'ils fournissent et ceux dont ils ont besoin.
    Il permet aussi de décrire clairement l' interconnection de tous les
    composants du système ainsi que les moyens qu'ils utilisent pour communiquer
    entre eux.\\

    \emph{SCA} fournit donc la structuration d'un système, et permet
    d'interconnecter des composants pouvant être implémentés dans des
    technologies différentes mais communiquant par des protocoles
    standardisés.\\

    Deux cas ont été envisagé pour l' utilisation de cette technologie:

    \begin{itemize}
      \item \emph{SCA/BPEL}: on a la possibilité d'implémenter un composant à
        l'aide d'un fichier \emph{BPEL} et de le faire communiquer avec les autres
        composants par l'intermédiaire d'interface \emph{WSDL}; ce qui peut être
        une solution interessante car on aurait à la fois structuration claire
        (\emph{SCA}) et orchestration(\emph{BPEL});
      \item \emph{SCA/Java}: dans cette optique les composants et leurs
        interfaces sont décrits à l'aide du language Java; l' orchestration doit
        ainsi se faire manuellement.
    \end{itemize}

  \item \emph{OpenESB:}~\cite{openesb}

    L' utilisation d'un ESB (\textbf{E}nterprise \textbf{S}ervice \textbf{B}us)
    tel que \emph{OpenESB} permet de faciliter la mise en oeuvre d'une
    architecture SOA.
    En effet un ESB met a disposition des développeurs des services de bases
    tels que:

    \begin{itemize}
      \item la gestion d'évènements;
      \item l' exposition des services;
      \item une communication fiable entre les services.\\
    \end{itemize}

    \emph{OpenESB} est livré avec le serveur d' application \emph{Glassfish}
    ainsi que l' environnement de developpement \emph{Netbeans IDE}.
    Ces deux outils sont étroitement liés et offrent un environnement de travail
    propice au développement SOA.\\

    L' utilisation de cette technologie s' orienterait vers une optique
    \emph{BPEL/WebServices}:

    \begin{itemize}
      \item \emph{Netbeans IDE} permettrait de définir de façon aisée des
        fichiers BPEL et de gérer leur déploiement sur le serveur d'application;
      \item les \emph{WebServices} pourraient être exposés comme des entités, ce
        qui déléguerait au serveur d' application \emph{Glassfish} la gestion de
        leur cycle de vie ou encore la persistance.
    \end{itemize}

  \item \emph{Bonita:}~\cite{bonita}

    Bonita est une solution \emph{open source} de \emph{Business Process
    Management}.
    Bonita Studio --- l'\emph{IDE} proposé par ce logiciel --- permet la
    collaboration de processus métiers selon la norme BPMN.

    L'avantage de cette solution est qu'elle permet la mise en œuvre de diverses
    technologies au sein d'un même workflow.

  \item \emph{WebServices:}

    L'idée ici serait d'utiliser le formalisme \emph{BPEL} pour l' orchestration
    et pour la construction de services composites.
    Les services seraient déclarés en tant que \emph{WebServices} et exposés sur
    le réseau local comme le montre l'exemple
    \ref{cod:sample_local_webservices}.

    L'utilisation de cette méthode nécessite d' avoir à gérer un moteur
    d'exécution de \emph{BPEL} tel que Apache ODE, qui pourra prendre en charge
    la gestion du cycle de vie des \emph{BPEL} qui y seraient déployés.

    \begin{code}
      \begin{lstlisting}
package fr.alma.domo;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.xml.ws.Endpoint;

@WebService(targetNamespace="http://helloworld/ws",
    name="HelloWorldTest",
    serviceName="helloWorld")
public class HelloWorld {

  @WebMethod(operationName="sayHello")
  public String sayHello(@WebParam(name="name", mode=WebParam.Mode.IN) String name){
    return "Hello "+name;
  }

  @WebMethod(exclude=true)
  public static void main(String[] args){
    // Le WSDL Sera dispo a l'addresse
    // http://localhost:12356/helloWorld?wsdl
    String endpoint = "http://localhost:12356/";
    Endpoint.publish(endpoint, new HelloWorld());
  }

}
      \end{lstlisting}
      \label{cod:sample_local_webservices}
      \caption{WebService et Java}
    \end{code}

\subsubsection{Différence entre ces technologies}

Le choix de la technologie permettant l'implémentation d'une solution concrète
se base sur un ensemble d'attentes et de critères à même de définir en quoi la
solution choisie sera la plus adaptée.\\

Le cœur du projet portant sur la composition de services, nous nous devions de
choisir une technologie permettant une gestion efficace des services, ainsi que
la possibilité de réutiliser un service composite comme composant d'un autre
service.

Un autre critère indispensable porte sur la possibilité de déployer, d'exécuter
les services, dans la mesure où un exemple concret est attendu, faisant office
de \emph{proof of concept}, attestant la faisabilité des concepts appliqués
dans ce projet.\\

Viennent s'ajouter à ces critères primordiaux certains autres, moins
indispensables mais non-négligeables, tels que:

\begin{itemize}
  \item la facilité d'utilisation de l'outil;
  \item la possibilité de bénéficier d'une représentation graphique de
    l'orchestration des services métiers au sein d'un service composite.
\end{itemize}

\begin{table}[htb]
  \centering
  \caption{\label{fig:comparative_table} Comparatif sur les solutions
    implémentatoires}
  \begin{tabularx}{\textwidth}{|>{\centering\arraybackslash}X|
    >{\centering\arraybackslash}X|>{\centering\arraybackslash}X|
    >{\centering\arraybackslash}X|>{\centering\arraybackslash}X|}
    \hline
    & Composition de services & Services exécutables & Facilité d'utilisation &
    Visualisation de l'orchestration\\
    \hline
    \emph{SCA Tools} & Oui & Non & Oui & Oui\\
    \hline
    \emph{OpenESB} & Oui & Oui & Non & Oui\\
    \hline
    \emph{Bonita} & Non & Oui & Oui & Oui\\
    \hline
    \emph{WebServices} & À implémenter & Oui & Oui & Non\\
    \hline
  \end{tabularx}
\end{table}

Le tableau \ref{fig:comparative_table} illustre en quoi les solutions vues
précédemment répondent ou non à ces différents critères.\\

Si \emph{SCA Tools} propose un environnement directement adapté à la composition
et l'orchestration de services, nous ne sommes hélas pas parvenu à les déployer
sur un serveur d'application en vue d'une exécution.
Dans ces conditions, il s'est avéré que nous ne pouvions utiliser SCA Tools en
corrélation avec des fichiers de description de services au format BPEL.

En ce qui concerne \emph{OpenESB}, il permet sans une certaine mesure la
composition de services et le déploiement de ceux-ci.
Cependant, la difficulté d'utilisation, lié à un environnement de développement
lourd et non exempt de bugs en font une technologie difficile à manipuler, ce
pour quoi nous l'avons mise de côté.

\emph{Bonita} ne permettant pas une composition avancée --- en ce sens qu'un
projet Bonita ne peut être réutilisé en tant que processus simple d'un autre
projet --- il ne correspondait pas là non plus à nos attentes.\\

Pour ces raisons, nous avons opté pour le développement d'une architecture de
services composites basés sur une implémentation de services en Java lié à
\emph{SCA}.
Reste ici à développer et implémenter une solution efficace afin de répondre aux
exigences des gestionnaires de collaboration et d'adaptation.

\section{Implémentation}
\label{Implementation}

La solution que nous avons choisi d'implémenter se base sur l'utilisation de la
composition de services proposée par SCA Tools, à laquelle vient se greffer une
implémentation de notre métamodèle dans le langage Java.

Après une rapide présentation de SCA Tools, nous reviendrons en détail sur
l'implémentation de notre métamodèle d'une part, et de son instanciation dans
le cadre de la lecture de musique d'autre part.

\subsection{Présentation de SCA Tools}

SCA Tools est un environnement de composition et de développement de services au
sein de l'IDE Eclipse.

SCA Tools propose une collection d'outils permettant l'implémentation et
l'exécution du formalisme SCA (\emph{Service Component Architecture}).

Parmi ces outils se trouvent notamment:

\begin{itemize}
  \item le métamodèle SCA tel que défini par l'EMF (\emph{Eclipse Modeling
    Framework});
  \item le \emph{SCA Composite Designer}, un environnement graphique permettant
    la construction d'applications composites, tel que l'illustre la figure
    \ref{fig:scatools}.
\end{itemize}

\begin{figure}[htb]
  \begin{center}
  \includegraphics[width=\textwidth]{images/scatools.png}
  \caption{SCA Composite Designer}
  \label{fig:scatools}
  \end{center}
\end{figure}

\subsection{Implémentation du métamodèle}

\subsubsection{Définition d'une ressource}
% Ici ce serait cool d'introduire AbstractService

Dans cette section, nous allons expliquer plus en détails en quoi consiste
notre classe «~Resource~» sur laquelle de nombreuses autres reposent.

Tous les services décrits dans notre conception qu'ils soient métiers,
gestionnaires ou composites reposent sur cette classe. En effet, celle-ci est
la classe centrale sur laquelle s'appuient les services.\\

Tout d'abord, chaque ressource est identifiée par un \emph{rid} unique et
possède deux attributs. Le premier étant un attribut permettant de vérifier si
la ressource est instance d'une classe et le deuxième permettant de définir la
description liée à cette ressource.

Ensuite, un registre qui contient tous les services créés est mis en place afin
de pouvoir connaître tous les services existant dans le système. De plus, deux
\emph{Map} sont créées afin de stocker les différents états des ressources et
les listeners qui leurs sont associés.

Le constructeur de cette classe prend en entrée uniquement un String en
paramètre, celui-ci représentant la description de cette ressource.\\

En ce qui concerne le mécanisme de découverte et sélection d'un service, une
méthode a été implémentée permettant de voir si un service correspond aux
critères de recherche de l'utilisateur. Celle-ci permet donc de voir si la
description passée en paramètre correspond à celle recherchée par le client.

De plus, un appareil tel qu'un lecteur ou un haut-parleur peut tomber en panne.
Un paramètre de celui-ci est alors modifié et cette modification est repertoriée
afin que le service connaissent les appareils defectueux et/ou non
utilisable.\\

Enfin, plusieurs méthodes permettant l'accès et la modifications d'attributs ou
encore l'ajout ou la suppression d'entrées dans une Map ou dans le registre ont
été implémentées pour en simplifier l'utilisation.

\subsubsection{Composition de services}

L'implémentation de la composition de services à proprement parler --- au sens
défini par notre métamodèle --- se base sur la spécification proposée par
\emph{SCA Tools}.

En effet, \emph{SCA Tools} propose, dans sa spécification d'un métamodèle SCA,
des concepts et fonctionnalités que l'on retrouve dans notre métamodèle, ce qui
facilite dès lors son implémentation.
Ainsi, il s'agit dès lors de réutiliser ces concepts afin de venir y greffer les
spécificités soulevées dans la conception de notre métamodèle.\\

Parmi ces spécificités se trouvent notamment les services gestionnaires.
Si, dans le métamodèle proposé par l'\emph{EMF} au sein de \emph{SCA Tools}, on
retrouve quelques uns des aspects auxquels se consacrent nos gestionnaires, la
séparation de ceux-ci au sein de trois gestionnaires --- de collaboration,
d'adaptation et de contexte --- est propre à notre métamodèle.

Afin d'implémenter cette vision des choses, et dans la mesure où tous les
services, gestionnaires compris, sont considérés comme des ressources dans notre
implémentation, voici comment nous avons défini chacun des trois
gestionnaires:\\

\begin{enumerate}[1.]
  \item \emph{Gestionnaire de collaboration}:\\
    Notre implémentation du gestionnaire de collaboration se base sur trois
    classes et interfaces:
    \begin{itemize}
      \item \emph{CollaborationSchema}: cette interface décrit un ensemble
        d'attributs et de méthodes propres à permettre l'instanciation efficace
        d'un schéma de collaboration tel que défini via l'éditeur graphique de
        \emph{SCA Tools}; elle sera également appelée par le gestionnaire
        d'adaptation lors du remplacement d'un service métier concret par un
        autre;
      \item \emph{Collaboration}: cette classe se charge quant à elle
        d'instancier effectivement un schéma de collaboration, ce en vue de
        déployer le service composite; c'est elle qui fait le lien entre notre
        métamodèle et l'interface d'instanciation et de déploiement proposée par
        \emph{SCA Tools};
      \item \emph{CollaborationHandler}: cette interface, notre gestionnaire de
        collaboration à proprement parler, offre quant à elle des méthodes
        répondant aux fonctionnalités attendues, telles que la création d'un
        schéma de collaboration, l'instanciation de celui-ci et la suppression
        de cette instance; une implémentation, \emph{CollaborationHandlerImpl}
        est également définie, elle étend également la classe
        \emph{AbstractService}.\\
    \end{itemize}
  \item \emph{Gestionnaire d'adaptation}:\\
    Deux couples de classe et interface entrent ici en compte:
    \begin{itemize}
      \item \emph{SelectionAndDiscovery}: cette interface propose un ensemble
        de méthodes qui permettent de chercher des services parmi ceux
        disponibles en fonction de leurs descriptions ou de leurs ontologies;
      \item \emph{AdaptationHandler}: cette interface est notre gestionnaire
        d'adaptation en tant que tel; dans son implémentation, une méthode
        \emph{onAdaptationNeed} est définie , c'est elle qui sera appelée
        lorsqu'un service devra être remplacé par un autre; la recherche de
        services correspondant aux attentes du schéma de collaboration sera
        déléguée au service \emph{SelectionAndDiscoveryImpl}.
    \end{itemize}
    La gestion dynamique de l'adaptation se fait à l'aide d'un patron de
    conception proche du pattern \emph{Observer}, à savoir qu'une annotation
    \emph{Watcher} a été définie.
    Les méthodes annotées par \emph{Watcher} seront dès lors en mesure
    d'observer les ressources en fonction de leur ontologie, passé en paramètre
    de l'annotation.\\
    Dès lors, la méthode \emph{onAdaptationNeed}, annotée par \emph{Watcher},
    pourra mettre en œuvre le remplacement d'un service lors de la défaillance
    de celui-ci --- évènement mis en évidence par le service d'instanciation de
    collaboration.
  \item \emph{Gestionnaire de contexte}:\\
    Le gestionnaire de contexte est destiné à permettre la persistance de
    données.
    Cependant, l'ensemble des données qu'on peut être amené à vouloir conserver
    d'une exécution à l'autre d'un service composite est particulièrement
    vaste.\\
    Dans ces conditions, nous avons créé une interface \emph{Context} imposant
    via la méthode \emph{getId} l'existance d'une clé pour chaque contexte
    concret.
    C'est dans les classes implémentant cette interface que devront figurer les
    données à conserver.\\
    L'interface \emph{ContextHandler}, en tant que gestionnaire de contexte,
    offre dès lors un ensemble de méthodes destiné à permettre la persistance
    d'un contexte.
\end{enumerate}

\subsection{Instanciation du métamodèle}

%% A voir plus tard!!

Le choix SCA/java est utilisé dans notre implémentation pour décrire, exposer et
interconnecter les  différents services  du système.
Nous présentons dans cette instanciation de notre métamodèle correspondant au scénario de lecture de musique.
Le diagramme \ref{M1} correspond   au contenu du service composite musique.
\begin{figure}[h]
\begin{flushleft}
\includegraphics[width=\textwidth]{images/SCMPlayer.jpg}
\caption{Composition du service composite lecture}
\label{M1}
\end{flushleft}
\end{figure}
Nous détaillons toutes les classes et interfaces que nous  avons définis   pour
implémenter   les  services nécessaires  à la  simulation  du  scénario de lecture de musique  d’un résident.
\begin{enumerate}
  \item \textbf{Interface:}
\texttt{Ressource:}

Une classe abstraite représentant une ressource.
Toute ressource doit heriter de cette classe.
Elle contient comme attributs:

\begin{itemize}
  \item un attribut de type booléen  contenant la valeur \emph{true} si la
    ressource est de type «~Class~» et \emph{false} sinon;
  \item un contenant le type de la ressource par exemple: lecteur, hp, etc;
  \item un annuaire (Map) de tous les services disponibles par type de service;
  \item la liste des ressources observant la ressource.
\end{itemize}

Cette classe contient en plus des accesseurs et modificateurs de ces derniers
ainsi que d'autres méthodes permettant de stocker ou d'extraire des informations
sur la ressource.\\

\texttt{Context:}

une interface étendant la classe Serialisable afin de sérialiser à tout moment le
contexte de l'utilisateur.\\

\texttt{AbstractService:}

Cette classe abstraite représente tous les services du système. Tout service doit hériter de cette classe et redéfinir ses méthodes abstraites.\\

\texttt{CollaborationSchema:}

Permet de définir un schéma de collaboration entre  plusieurs services.

Elle contient comme méthodes:

\begin{itemize}
  \item \emph{getDescriptionFor():} prend en entrée une chaine de caractères et
    renvoie une description «~Description~»;
  \item \emph{negociate():} cette méthode est appelée lors de l'instanciation du
    schéma de collaboration lorsque tous les services lui ont été injectés;
  \item \emph{renegociate():} cette méthode est appelée lorsque le gestionnaire
    d'adaptation a remplacé un ou plusieurs services qui ne correspondaient plus
    aux contraintes spécifiée dans la construction du schéma.\\
\end{itemize}






    \texttt{ExecutionService:}

    C'est une interface contenant la méthode «~execute~» prenant comme paramètre
    un lecteur et un haut parleur.\\

    \texttt{MusicPlayerSCM:}

    Cette interface est la façade du service composite métier de lecture de
    musique.

    Elle fournit comme méthodes:

    \begin{itemize}
      \item getPosition(): prenant comme paramètre l'identifiant du client et
        retournant sa position;
      \item selectPlayer(): reçoit le titre d'une musique comme paramètre et
        renvoie un lecteur contenant  le titre;
      \item selectHP(): renvoie un haut parleur hp se trouvant à la position
        pos passé en paramètre;
      \item play(): renvoie vrai si le couple (lecteur, haut parleur) passé en
        paramètre s'exécute.\\
    \end{itemize}

    \texttt{PositionService:}

    Cette interface fournit des méthodes permettant de rechercher la position d'un client
    par rapport à certains critères (id, nom, etc) ainsi qu'une méthode permettant
    de sauvegarder la position du client.

    Elle fixe toutes les positions existantes dans le système (dehors, cuisine,
    salon, chambre, etc) en les stockant dans des constantes.

  \item \textbf{classes:}

    \texttt{ClientContext:}

    Cette classe représente le contexte d'un client, elle étend la classe
    abstraite «~Ressource~» et implémente l'interface «~Context~».

    Elle contient les données suivantes:

    \begin{itemize}
      \item la position du client;
      \item le nom du client;
      \item l'identifiant unique du client;
      \item et sa priorité.
    \end{itemize}

    Elle fournit tous les accesseurs et modificateurs de ces attributs
    .\\

    \texttt{PlayerHPCollaboration:}

    Cette classe implémente les méthodes de l'interface CollaborationSchema.

    Elle permet lier un lecteur à un haut parleur.

    Elle stocke comme attributs:

    \begin{itemize}
      \item une référence d'un lecteur concret;
      \item une référence d'un haut parleur;
      \item les descriptions du type de collaboration;\\
    \end{itemize}

    \texttt{ExecutionServiceImpl:}

    Elle représente le service d'exécution de la lecture de musique.
    Elle étend la classe abstraite AbstractService et implémente la classe
    executionService.
    Elle contient une instance de la classe CollaborationHandler gérant la
    collaboration des ressources et implémente la méthode execute() exécutant un
    lecteur et un haut-parleur passés en paramètres.\\

    \texttt{MusicPlayerSCMImpl:}

    Elle implémente le service composite métier de la lecture de musique en
    étendant la classe AbstractService et MusicPlayerSCM.

    Elle contient comme attributs:

    \begin{itemize}
      \item positionService: stockant une référence du service de position
        permettant de rechercher une position;
      \item selectionAndDiscovery: le service de découverte et de sélection
        permettant de chercher un lecteur et un haut parleur disponibles et
        répondant aux critères du client;
      \item executionService: contient  la référence du service d'exécution
        permettant de lancer l'exécution du couple (lecteur, haut parleur);
    \end{itemize}

Elle contient aussi des méthodes interrogeant ces services stockés.\\

    \texttt{MusicServiceImpl:}

    Elle implémente le service musique en étendant la classe AbstractService et
    MusicService.

    Elle possède une référence du service composite métier de lecture de musique
    MusicPlayerSCM et définit aussi la méthode playSong(client,title)
    déléguant l'exécution au service MusicPlayerSCM.\\

    \texttt{PositionServiceImpl:}

    Elle implémente le service position en étendant la classe AbstractService et
    PositionService.

    Elle contient une référence du gestionnaire de contexte permettant de
    retrouver le contexte d'un client.

    Elle fournit des méthodes pour rechercher le contexte et la position d'un
    client.

\end{enumerate}

\section{Difficultés rencontrées}
\label{difficultes}

Au cours de la réalisation de ce projet, nous nous sommes heurté à certains
problèmes, certaines difficultés, ce tout au long du travail de spécification et
d'implémentation, qu'il s'agisse du métamodèle de services composites que de
l'instanciation de celui-ci dans le cadre de la domotique.\\

Dès le départ, la compréhension et la maîtrise des concepts liés au paradigme de
composition de services aura été une première étape à atteindre afin de pouvoir
par la suite le raffiner en notre version du métamodèle.

En outre, les différents niveaux d'abstraction que recquièrent de manière
générale les paradigmes à composants représentent une difficulté supplémentaire
dans la spécification de composants et de composites, et dans notre cas de
services.

En effet, la définition des services composites et de leurs services métiers, la
décision de savoir si un service métier était à son tour un composite ou non,
auront été une partie non négligeable de notre travail de conception.\\

En ce qui concerne la partie implémentation, c'est avant tout la découverte d'un
outil adapté, facile à prendre en main, efficace et fonctionnel qui aura été le
premier problème que nous avons eu à surmonter.

Par la suite, le développement d'une solution adaptée à SCA Tools et prenant en
compte les particularités du serveur Tuscany a été au cœur de nos
préoccupations.
En effet, si le déploiement de services composites se fait de manière efficace
et satisfaisante au travers des ces outils, c'est la possibilité de lancer une
routine au sein de celui-ci --- dans le cadre du gestionnaire d'adaptation qui
doit être opératoire à tout instant du déploiement d'un service composite ---
qui nous a posé problème de prime abord.

\section*{Conclusion}
\addcontentsline{toc}{section}{Conclusion}

Tout au long de notre travail sur ce projet de fin d'études, nous avons eu à
cœur d'apporter une solution rigoureuse, appuyée sur des bases solides et
sérieuses, ce afin d'amener le développement du projet à bien, ceux depuis les
prémices de la conception jusqu'à la réalisation d'une implémentation efficace.

Ainsi, si nous avons eu certains problèmes et difficultés à surmonter, nous
pensons être parvenus à proposer une solution répondant aux objectifs du projet,
en ce sens que nous mettons à disposition une implémentation solide et
fonctionnelle de notre métamodèle.\\

En conclusion, ce projet nous aura permis de mettre en application l'ensemble
des connaissances acquises durant notre master au sein d'un projet d'envergure
plus importante que nos projets habituels, selon une méthode plus encadrée, et
partant plus professionnelle.

La mise en application d'une architecture à composants couplé à la gestion de
services, ce au moyen d'outils dédiés, a été également une bonne expérience en
vue de notre insertion professionnelle.

\clearpage
\bibliographystyle{abbrv}
\bibliography{biblio}

\end{document}

